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The RICIS Concept 


The University of Houston-Clear Lake established the Research Institute for 
Computing and Information Systems (RICIS) in 1986 to encourage the NASA 
Johnson Space Center (JSC) and local Industry to actively support research 
In the computing and Information sciences. As part of this endeavor, UHCL 
proposed a partnership with JSC to Jointly define and manage an Integrated 
program of research In advanced data processing technology needed for JSC's 
main missions, including administrative, engineering and science responsi- 
bilities. JSC agreed and entered Into a continuing cooperative agreement 
with UHCL beginning In May 1986, to jointly plan and execute such research 
through RICIS. Additionally, under Cooperative Agreement NCC 9-16, 
computing and educational facilities are shared by the two Institutions to 
conduct the research. 

The UHCL/RICIS mission Is to conduct, coordinate, and disseminate research 
and professional level education In computing and Information systems to 
serve the needs of the government, industry, community and academia. 
RICIS combines resources of UHCL and its gateway affiliates to research and 
develop materials, prototypes and publications on topics of mutual interest 
to Its sponsors and researchers. Within UHCL, the mission is being 
Implemented through Interdisciplinary Involvement of faculty and students 
from each of the four schools: Business and Public Administration, Educa- 
tion, Human Sciences and Humanities, and Natural and Applied Sciences. 
RICIS also collaborates with Industry In a companion program. This program 
Is focused on serving the research and advanced development needs of 
Industry. 

Moreover, UHCL established relationships with other universities and re- 
search organizations, having common research Interests, to provide addi- 
tional sources of expertise to conduct needed research. For example, UHCL 
has entered Into a special partnership with Texas A&M University to help 
oversee RICIS research an! education programs, while other research 
organizations are Involved via the “gateway” concept 

A major role of RICIS then is to find the best match of sponsors, researchers 
and research objectives to advance knowledge In the computing and informa- 
tion sciences. RICIS, working jointly with its sponsors, advises on research 
needs, recommends principals for conducting the research, provides tech- 
nical and administrative support to coordinate the research and Integrates 
technical results Into the goals of UHCL, NASA/JSC and Industry. 
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1 Introduction 

The Framework Programmable Software Development Platform (FPP) is a 
project aimed at effectively combining tool and data integration 
mechanisms with a model of the software development process to provide 
an intelligent integrated software development environment. Guided by the 
model, this system development framework will take advantage of an 
integrated operating environment to automate effectively the management 
of the software development process so that costly mistakes during the 
development phase can be eliminated. This Platform is being developed 
under the Advanced Software Development Workstation (ASDW) Program 
sponsored by the Software Technology Branch at the NASA Johnson Space 
Center. The ASDW program is conducting research into development of 
advanced technologies for Computer Aided Software Engineering (CASE). 

1.1 Motivations for the FPP 

The FPP was conceived in response to difficulties of producing software 
systems. With the advent of more powerful and more economical computer 
hardware resources, the complexity of software systems has increased 
dramatically. As computer systems become more complicated, ensuring 
that systems are produced in a consistent manner, on time, and within 
budget, and ensuring that the system built is reliable and maintainable, 
requires a considerable management effort. 

One characteristic of large software systems is the inability of a single 
person to fully understand the requirements, produce the design, and 
develop the system. Instead, the system development process must be 
executed by a team of managers and software engineers. Tasks within the 
development can occur concurrently, except where certain tasks depend on 
information produced by others. These interrelationships make the 
management of the development process very difficult. Regardless of how 
well a development project may be planned out, without some form of 
control over the actions of the development team, costly mistakes and 
setbacks are bound to occur during development. This is particularly true 
in multi-year projects that suffer from management and technical team 
leadership turnover. 

One promise of Computer Aided Software Engineering (CASE) tools was to 
assist project managers in monitoring the progress of the development 
activities and in capturing the experiences of the development team. 
However, the existing CASE tools fail to cover the entire software 
development process and tend to concentrate instead on a particular aspect 
of the development process (i.e., project management, requirements 
analysis, code development and debugging). The result has usually been to 
use a piecemeal collection of various CASE tools that addresses only 
portions of the development process during the development of software 
systems. 
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Many of these tools are quite useful within their specified area of the system 
development process. However, a persistent problem with these tools has 
been in trying to use the tools in some organized fashion to fully automate 
the system development process. Incompatible data formats along with the 
misuse of tools make interaction among these different tools very difficult. 
As a result, development of CASE environments that effectively automate 
the software engineering process are nonexistent. 

The recognition of these difficulties has spurred the development of the 
FPP. The focus of the FPP is the management, control, and integration of 
the software system development process. The major goals in this 
definition of the FPP have been to provide: 

1) a realistic integration strategy that supports function and 
data integration of a suite of tools (distributed and 
covering the entire life-cycle); 

2) integrated access to and update of life cycle artifact data; 

3) control of life cycle activities and data evolution; and 

4) a site-specific development process support environment, 
enforcing the rules and preferred methods of the 
organization. 

The FPP is also expected to provide these capabilities in a distributed, 
heterogeneous computing environment. Developing a platform that meets 
these goals should result in (1) a reduction in the time required to produce 
software systems, (2) an increase in the quality of the resulting software 
systems, (3) a decrease in the maintenance effort for the resulting software 
systems, and (4) an increase in the consistency in the development process 
by which software systems are constructed. 

1.2 Scope of this Document 

Previous work on the FPP project focused on the development of an 
integration strategy and design of the mechanisms to support that strategy. 
The result has been the production of concept and design documents 
detailing the Integration Services approach to integration [FPP 90a], [FPP 
91a]. With this service based approach, an application advertises the 
services it will provide, as well as the invocation procedures for that service. 
In essence, the advertisements define external interfaces that allow other 
tools or users to take advantage of the functionality provided by the new 
application. The underlying integration platform provides the required 
support for organizing and maintaining these interface definitions, as well 
as for routing the integration service requests. 

Though much of the work on the FPP to this point has dealt with integrated 
development environments, the major focus throughout the project has 
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been on the framework. As will be discussed in more detail in Section 2, a 
framework provides a description of the entire system development process, 
and a goal of the FPP project is to use this description to guide users 
through and to manage that development process. The Framework 
Processor mechanism [FPP 91b] will provide the functionality to process 
and interpret the framework description to guide users through the 
development of systems. In a fully operational environment, the integrated 
environment is necessary to provide an underlying architecture upon 
which the framework processing can be layered. The flexibility of the 
integration services approach will give the integrated development 
environment the ability to support framework processing. 

At this point in the FPP project, the design phase has now been completed 
and the FPP project is entering the demonstration prototyping stage. In 
this stage, work is progressing on the development of prototype systems that 
provide the type of functionality specified in the FPP Concept of Operations 
Document [FPP 90a] and the FPP Requirements Document [FPP 90b] and 
that adhere to the designs presented in [FPP 91a], [FPP 91b], and [FPP 91c]. 
Currently, the prototype under development addresses the framework 
processing capability defined in the Framework Processor Design 
Document [FPP 91b]. 

However, a requirement for the demonstration of this framework 
processing capability is the existence of a framework for the platform to 
manipulate and to use in guiding a development process. Since this 
framework is used to manage and control the system development process 
at a specific site, an organization should not take its production lightly. In 
recognition of the importance of the framework definition, a task to 
generate a demonstration framework for use in testing and running the 
prototype system was included in the FPP effort. The results of this task are 
the contents of this document. 

1.3 Document Organization 

The presentation of the demonstration framework has been broken up into 
two documents. This document, Volume I, provides a discussion of the 
concepts behind the FPP, the evolution and structure of the demonstration 
framework, and a description of each of the activities in the development 
process. Volume II presents the IDEF3 process descriptions that are a 
major part of the demonstration framework. These two volumes should be 
used in unison to get a full understanding of the demonstration framework. 

The reader should begin, however, with this volume in Section 2, where a 
presentation of background concepts surrounding frameworks and the use 
of frameworks by the FPP is provided. Section 3 then presents the evolution 
that the demonstration framework has undergone since the development of 
the framework began. Section 3 also presents some interesting discoveries 
regarding frameworks in general made during the development of this 
framework. 
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It is in Section 4 that the definition of the framework actually begins. At 
this point, the user may want to read Volume II in conjunction with 
Section 4. While Section 4 describes each activity, Volume II presents the 
overall process in which the activity occurs. By examining both views at the 
same time, the reader can grasp the context in which the activity takes 
place along with an understanding of what takes place within that activity. 

Finally, the document is concluded with a brief discussion of future 
directions. A bibliography of source material is also provided along with a 
development process comparison chart found in Appendix A. 
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2 Frameworks Background 

In order for a development environment to provide intelligent coordination 
and control throughout the software development process, the environment 
must have some means of understanding the intended development 
process. The means by which the FPP will capture this knowledge is 
through the framework. This section will provide a brief explanation of the 
framework concept as well as a description of how the FPP will use the 
framework to manage the software development process. 

2.1 Frameworks 

In general, a framework is a structure for organizing knowledge about a 
system. With respect to the FPP, a framework is a structure for organizing 
knowledge about: (1) situations occurring in the evolution of a software 
system, (2) methods and tools available for use in developing the software 
system, (3) the circumstances under which particular methods and tools 
should be used in support of a situation within the development process, 
and (4) the users and user roles responsible for addressing a situation 
within the development process. Recently, much research has been 
performed in the area of frameworks, and different views and classes of 
frameworks have evolved from this work. Two views of frameworks are of 
particular interest to the FPP and will be discussed in the next two 
subsections. 


2.1.1 Situation Classification Frameworks 

The first view of a framework is as an organizing structure for the many 
representations of information pertaining to an information system. Under 
this view, the parts being structured are development situations in which 
particular representations of the problem or its solution are developed or 
used. This is the view of the original Zachman framework [Zachman 86]. 

In this context, the term framework refers to an organization of 
characterized situation types that are known to occur commonly during a 
system life cycle. Each characterization identifies the roles of the personnel 
in the organization involved in that situation type and the information that 
must be discovered, decided upon, or managed during that situation. For 
example, one situation may involve two system analysts deciding on how to 
implement data in an information system. Another situation may involve 
an analyst presenting to the business owners the type of data needed for 
their company’s information system. In these two situations, the analysts 
are focusing on data, but from two different perspectives. Accordingly, the 
two different perspectives require different information about the 
information system. These two examples demonstrate how similar 
situations can vary drastically in scope and perspective. 
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Figure 2*1. The Zachman Framework 


This idea can be generalized. In the life cycle of an information system, 
different representations of information pertaining to the system are 
required at different stages of the development process. A Situation 
Classification Framework attempts to characterize the various 
development situations that require these different representations. John 
Zachman’s original Situation Classification Framework is shown in 
Figure 2-1. This framework is represented as a matrix in which the six 
rows represent different perspectives (or views) and the three columns 
represent focuses of descriptions of an information system architecture. 
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The perspective organizes the descriptions of the system with respect to 
multiple viewpoints (e.g., the executive, the manager, the programmer, 
etc.). The focus organizes the descriptions with respect to the level at which 
the system will operate. Thus, each cell in the matrix represents a 
situation with a particular focus from the perspective of a user’s viewpoint. 

The power of the framework lies in the identification of these different 
situation types, since the characterization includes identification of the 
roles, responsibilities, conditions, prior commitments, and information 
involved in a situation that results in a need for a particular class of system 
representation. This necessary representation can then drive the selection 
of specific methods for capturing that representation and for managing the 
information critical to that development situation. We can also identify 
where information needs to be shared from one development situation to 
another. Therefore, once this classification framework has been 
established, the framework can help a project member select the most 
effective tool to guide the system developers from the concept of a solution to 
the reality of an implementation. 

2.1.2 System Development Framework 

While the Situation Classification Framework view attempts to categorize 
the development situations that arise during system development, the 
Situation Classification Framework provides no means for capturing 
temporal relationships between the various situations. In addition, there 
are no means for capturing the details of the processes and activities that 
occur within the situation types. However, with the second view of a 
framework, the intent is to capture these procedural aspects of an 
organization’s system development process. In this respect, the second 
view of a framework is as an organizing structure for a system 
development process. Under this view, the parts being structured are not 
situations or methods but life cycle analysis, design, implementation, 
maintenance, or decision making activities. We refer to this view as the 
System Development Process Framework. 
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Figure 2-2. Precedence Relationships Between Situations 
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Conceptually, the System Development Framework can be layered on top of 
the Situation Classification Framework as reflected in Figure 2-2. The 
figure shows that the process description can capture the sequence of 
situations defined in the Situation Classification Framework that are 
encountered during the development process. The advantage, however, 
that the System Development Framework has over the Situation 
Classification Framework is that the development process description can 
“look” inside each cell of the framework to examine the activities that must 
occur to address the development situation represented by the cell in the 
framework. As a result, the development process description can be 
defined to a finer level of detail to include not only the sequencing of 
development situations, but also the definition of life cycle phases, 
development tasks, project milestones, and project documentation artifacts. 
This process analysis will also produce: 

1. descriptions of the procedures for analysis, decision 
making, and configuration control; 

2. calls for the application of specific methods to specific 
development tasks; 

3. definition of common information/data across the 
different methods; and 

4. development process user role definitions. 

Taken together, these data provide a complete description of the process by 
which an organization addresses the development situations occurring 
during the development of a system. 

2.1.3 The FPP Framework and Its Role 

The preceding discussion has presented the two framework views as being 
separate structures. In actuality, the two frameworks are closely linked. 
By moving down a level of abstraction from the Situation Classification 
Framework, it is apparent that each cell of the Situation Classification 
Framework points to more detailed information as shown in Figure 2-3. 
Part of this information is the process description that captures details of 
the activities involved in addressing the situation. Therefore, the System 
Development Framework is partitioned and distributed across the Situation 
Classification Framework. The FPP framework will take this approach 
towards the framework definition. The Situation Classification Framework 
will serve as an organizing structure for the information necessary to 
capture an organization’s development process. As a result, the 
framework matrix will not necessarily be obvious in the definition of this 
demonstration framework. In actuality, the framework serves as a nice 
concept by which the definition of the process based framework can be 
generated. 
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Figure 2-3. Framework Cell Contents 

With the definition of a framework, the intent is to capture a representation, 
of the system development process at a particular organization. This 
framework: 

1. provides structure for the description of the software 
development process; 

2. provides a “big picture” of the system development 
process; 

3. provides a “road map” for the participants in the system 
development process; 

4. identifies standard methods and tools; 

5. specifies applicable tools and methods at a site; 

6. assists in the planning and scheduling of the system 
development process; 

7. orchestrates the use of integrated tools and methods; and 

8. summarizes the standard development process at a site. 
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As a result, a framework provides a means to carry the experience base 
from one project to another within an organization. In addition, the 
framework can provide a degree of control over the system development and 
provide consistency between projects requiring multiple project 
coordination, management consistency, and personnel utilization. 

But the framework can do more than just provide a description of the 
development process. As the FPP project intends to show, the 
representation of the framework can be used to drive and configure an 
automated development support environment. Some of the capabilities that 
will be possible through the use of this approach are: 

1. Context Defined Tasking, 

2. Life Cycle Data Management and Control, 

3. Automated Project Status Reporting, and 

4. Automatic Problem Notification. 

These types of capabilities are possible because the framework completely 
defines the activities that will occur during the development process, the 
relationships between those activities, the objects (e.g., documents, code, 
and modules) that will be manipulated during a particular activity, and the 
roles of people that will be involved in the activity. In this environment, a 
Framework Processor [FPP 91bj component will serve as an interface to the 
framework definition for a project member. By logging into the system, the 
user will be presented with the framework definition. The user can then 
browse the framework in two modes. The first mode will allow the user to 
browse the entire framework so that the user could become familiar with 
the development process at a particular organization. In the second mode, 
the framework is presented to the user with respect to a specific project. 
With specific project information, the framework is capable of reflecting the 
current state of the project development (i.e., at what point in the process is 
development currently focused). The user can also use this mode to identify 
the tasks and activities in which they should be involved. 

This idea might be made clearer by examining the operation of the 
Framework Processor more closely. The basic operational philosophy of the 
Framework Processor is to take a framework as input, translate the 
framework into a set of constraints and facts, and then use the facts and 
constraints to monitor and control the development process. During this 
process, the set of facts and constraints are continuously updated as a 
result of actions by users and messages from the development environment 
(i.e., the notification of the occurrence of certain events). This dynamic 
situation is continuously monitored to detect inconsistencies between the 
process specified in the framework and the actual events occurring during 
the system development. In this way, the framework is used to control the 
progression of a project development by enforcing the process defined in the 
framework. 
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Important to this framework processing ability is defining a framework in 
a form that is processable by computer. The information describing the 
development process must be structured in a format that will allow efficient 
processing by the,, , Framework Processor. , For this reason, the 
demonstration framework has been defined using the IDEF3 Process Flow 
Description Method [Mayer 90] augmented with certain definitional 
information with respect to software tools available to an organization, 
system users in the organization, and other organization resources. As a 
result, the IDEF3 descriptions and the additional resource definition 
information will provide the FPP with the information necessary to monitor 
and guide an organization’s development process. 
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3.0 FPP Demonstration Framework Development 

Having developed an tinderstanding of how a framework could be used in a 
CASE environment and having designed a mechanism to process these 
frameworks, the next step is to define a demonstration framework that will 
serve to prove the concepts previously developed. The remainder of this 
document will be dedicated to describing the resulting framework along 
with the approach taken to define this framework. Describing the process 
taken in defining a framework is important as much discussion has taken 
place as to the benefits of a framework, but little work has been done 
towards actually defining a framework or documenting a procedure to 
define a framework. In this section, the process by which the NASA 
framework was developed is presented. No claims are made as to whether 
this is the proper way to define a framework. Instead, the process is 
discussed to provide future framework developers with information that 
might help in the definition of other frameworks. 

3.1 Framework Comparison 

The first step taken in the development of the demonstration framework 
was to gather various frameworks and compare them. This was done to try 
to gather the best qualities of each to use as the basis for the demonstration 
framework. Various sources have taken Zachman’s original idea and 
expanded it to include other row perspectives and column focuses to fit best 
with the system architecture they are using. The sources for the 
frameworks used in this comparison and the abbreviations used to identify 
them are summarized below. 


Abbreviation 

Framework; 

Zachman 

John Zachman [Zachman 86] 

KBSL 

Knowledge Based Systems Laboratory 
[Mathur 1989] 

IUG 

IDEF User’s Group [Feldman 91] 

BA/Ford 

Booz Allen/Ford 

BA/Ford 2 

Booz Allen/Ford Extensions 

KBSI 

Knowledge Based Systems, Inc. 


The comparison of these frameworks uncovered some interesting concepts. 
For example, the row names can be labeled in three ways: 

1. by generic role of people involved with the cells of a row. 
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2. by generic thing produced in the cells of a row, and 

3. by generic activity going on in the cells of a row. 

The following table gives a comparison between the various frameworks for 
the row names. The final column labeled KBSI contains examples of all 
three ways of labeling the rows. 


Zachman 

KBSL IUG 

BA/Ford | KBSI 

Objective/Scope 

Objective/Scope 

Scope 

Planning 

Owner 

Objective/ Scope 
Business Planing 

Model of the 
Business 

Domain/ Model of 
the Business 



Bus. Community 

Domain/Ontology 

Harmonization 

Model of the 

Information 

System 

Model of the 

Information 

System 

Owner 

Analysis 

Business Operator 
Models of Bus. 
Analysis/Bus. Sys. 
Design 

Technology Model 

Technology Model 

Designer 

Logical Design 

IRM 

Model of Info.Sys. 
Analysis&Info. 
Sys. Design 

Detailed 

Representation 

Detailed 

Representation 

Builder 

Physical Design 

Sys. Designer 
Technology Model 
Physical/ 
Implmntn Design 

Functioning 

System 

Functioning 

System 

Worker 

Implementation 

Implementor 
Detailed Represent. 
Code&Test 



Target 

Document 

User 

Task Centered Rep. 
Use System 




Operate & 

Maintain 

Maintainer 
ATA+Func. Sys. 
Operate&Maintain 


Column labels did not vary as much in the ways they were labeled, but 
there are quite a few more columns than were in the original Zachman 
matrix. Zachman maintains that the original three columns contain the 
description of the entire system and that any other columns added to the 
framework must be taking descriptions from one of the other column. The 
reasons that one might want to split a column in this way might be to focus 
on a specific area of the system. Large complex matrices can be created 
with the splitting of columns in this manner. This may or may not be a 
problem depending upon the uses of the framework under consideration. 
The following table displays the comparison of frameworks with respect to 
columns. 
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3 J2 Framework Evolution 

After completing the comparison of the various frameworks, work began on 
defining the actual structure of this demonstration framework. The first 
step in this process was to identify and define the rows and columns of a 
framework that would be pertinent to a NASA system development. The 
rows of this framework settled on essentially the same rows found in the 
frameworks described in the previous sections and are summarized below 
in relation to Zachman’s original rows. 

1. The Program Manager could serve as the Business 
Owner. 

2. The Chief Engineer could serve as the Business Operator 

3. The Project Director could serve as the IRM/System 
Manager 

4. The System Designer perspective could remain the same. 

5. The Implementor perspective could remain the same. 

The columns, however, were selected from the superset of all the columns 
found in the various frameworks. The chosen columns are briefly describe 
below. 

1. The Data column focuses on the data provided by, 
managed by, or necessary for the system. 

2. The Function / Process column focuses on the functions 
provided by the system as well as the processes by which 
the system operates. 
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3. The People col umn focuses on the structures necessary 
for man/machine interfaces. 

4. The System Structures column focuses on the 
representation of system architectures. 

5. The Lifecycle column focuses on the life cycle of the 
system (e.g., funding periods, phase definitions, etc.). 

6. The Lifecycle Artifact Management column focuses on the 
definition and configuration control of the artifacts that 
make up the system (e.g., requirements and design 
documents, code modules, etc.). 

Having settled on these rows and columns, work began on defining the 
situations represented by each of the cells in the resulting framework. 
However, in attempting to bound the situations represented by each cell of 
this framework, the development team constantly encountered the problem 
of shifting viewpoint. Were we examining data with respect to (1) the 
process by which the system is being built (2) what was being built, or (3) 
how the system was going to be used? 



Figure 3-1. Situation Framework Types 
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With further examination, it became clear that a possible third axis could 
by added to the framework matrix. This idea is reflected in Figure 3-1 by 
showing that there exists multiple situation framework types for the same 
system. In this work, three framework types were identified: 

1. the System Architecture framework captures the 
situations relevant to defining what the system is; 

2. the System Development framework captures the 
situations relevant to how the system will be constructed; 
and 

3. the System Use framework captures the situations 
relevant to how the system will be used and what will be 
required to use it. 

It has been said in the past that different frameworks exist for different 
system types. Here is evidence that different frameworks could exist for not 
only the same system type, but also for the same system. This third axis of 
the framework has been given a label of ‘Attitude,’ as each of the 
framework types represents a certain attitude to which the system is 
directed. 

Faced with the task of now defining three frameworks as opposed to one, 
the development team stepped back to reevaluate the situation. In this 
reevaluation, the team noticed that the Situation Classification Framework 
tended to ignore much of the process oriented aspects of system 
development and instead focused on certain instances of time within the 
process. As the FPP effort contends that the process represents a more 
fundamental view of system development and as the inherent complexity of 
the Situation Classification Framework became more obvious, work began 
to focus more on the development process and less on the development 
situation. 

3.3 Source Material 

Having decided to focus on the development process and to derive a 
framework for the development process, the next step was to gather source 
material on which to base the development framework. This section 
describes the various source materials that were used to define and develop 
the demonstration framework. After deciding to move away from the strict 
matrix form of the framework, the design team focused on actual software 
development methods that could be found in the literature. The basic 
processes that were examined are similar in nature, differing only in small 
details and occasionally in level of granularity or scope. Each tends toward 
the basic waterfall software life cycle which is prevalent throughout this 
area. In Appendix A, a chart is given that shows a comparison of the 
various development methodologies. The low level details are not covered by 
the chart as it was used only to give a general idea as to how the 
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methodologies measure up with one another. For a more detailed 
description, the reader is directed to the sources of the methodologies given. 

The following subsections provide an overview of the various methods and a 
discussion of why that particular method was a useful source of 
information. The methods are presented in roughly the order of most to 
least used. The SMAP documents were by far the most referenced source of 
information. As SMAP is a product of NASA, it was felt that a 
demonstration framework that was developed from the SMAP standards 
would be a more suitable example. The SEM document was another source 
that was used extensively. Although it was designed for the more general 
class of engineering development, it was useful in describing the software 
engineering development as well. The SDM from Westinghouse gives a 
superb outline of software development. This was almost used as the basis 
for the demonstration framework; however, there was not a large enough 
volume of information to develop a suitable demonstration framework. 

The following subsections describe the various sources of process 
information used for this demonstration framework. 

3.3. 1 Software Management and Assurance Program (SMAP) 

The SMAP document [Callendar 89] was used extensively in the 
development of the demonstration framework described in this document. 
The purpose of the SMAP is to define a standard life-cycle model and 
content for associated documentation. This standard provides an 
architecture to allow consistency across the agency using the SMAP. It 
also provides visibility into the completeness of the information recorded 
during the life-cycle. The only deficiency in using the SMAP was that it 
does not define specific role types to specific activities. The document states 
that this was intentional and that the assignment of specific tasks and roles 
should be decided by the project/program management. Other than this 
problem, the SMAP was very suitable to form into a demonstration 
framework. 


3.3.2 Systems Engineering Methodology (SEM) 

The SEM document is the result of research performed to support the 
orderly implementation of truly integrated manufacturing systems 
[Kemmel 83]. Even though this document focuses on manufacturing 
engineering methods and procedures, much of the information pertains to 
the development of software as well. The description of tools, role types, and 
methods that were lacking in the SMAP documentation can be found in this 
source. The IDEFO model of the system development process for integrated 
manufacturing systems was also of great help in defining the 
demonstration framework in this document. 
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3.3.3 Systems Development Methodology (SDM) 

The SDM, developed by Westinghouse Electric Corporation [Brunson 91], is 
a set of tools and techniques to assist in the recognition, assessment, and 
control of risk so that they may be acted upon at the earliest possible time. 
SDM provides an organized approach to project management. It is a 
methodology that is used in the planning and management of the systems 
development life cycle. The SDM booklet was useful in identifying roles and 
responsibilities during the software development life cycle. 

3.3.4 Alternative Architecture Display System Development 
Methodology (Alt. SDM) 

The goal of Alternate SDM [Peters 79] was to analyze the state of the art of 
system development in a manufacturing environment. This work was not 
as applicable as the previous despite the fact that the processes involved in 
manufacturing are often very similar when placed in a system 
development context. The study of methodologies from different domains, 
however, was helpful in completing the demonstration framework. 

3.3.5 IE/IMPACT 

IE/IMPACT, a product of Pacific Information Management [Coleman 90], 
is a comprehensive methodology that describes an approach to Enterprise 
Information Engineering that can be used to guide the achievement of 
Enterprise wide, integrated Information Resource Management. The 
philosophy of IE/IMPACT is to view the information of an enterprise as a 
resource and manage it in the same way as other enterprise assets. The 
steps of IE/IMPACT embody much more than the software development life 
cycle. < 

3.3.6 Others 

The other system development process sources that were examined for this 
work played a more tangential role. Typical software engineering, 
structured design, and systems analysis textbooks were employed to provide 
information on roles, tools, and methods for software engineering. These 
sources were helpful, but not crucial to the development of the 
demonstration framework. They were included in Appendix A for 
completeness. 

3.4 Development Activities 

After performing an analysis of the various development processes 
documented in the materials just described, the generation of the 
development process framework began. Before developing an IDEF3 
description of the augmented SMAP process, a partial IDEFO activity model 
was produced. This model was used to capture relationships between the 
activities in the development process. More specifically, this model was 
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used to identify the flow of artifacts between activities in this development 
process. 

Once the artifact relationships had been identified, the IDEF3 process 
description for the framework was generated. This description was 
generated using the prototype IDEF3 tool produced for NASA in 1990 and 
the resulting descriptions make up the contents of Volume II. The final 
step in the demonstration framework development was to merge the 
information captured in the IDEFO model with the IDEF3 process 
descriptions. This final step is essentially the contents of Section 4. In this 
section, a description of each of the activities (UOBs) occurring in the 
process description is provided. This description is defined in terms of the 
artifacts manipulated by, user role types participating in, tools available 
for, and methods recommended for the activity. Also included in this 
description is the definition of the criteria that must be met in order to 
consider a particular activity complete. 
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4.0 Framework Activity Definition 

This section begins the actual definition of the demonstration framework. 
To start off, definitions of the user roles, tools, methods, and artifacts used 
by the framework are provided. These definitions are then followed by 
descriptions of each activity in the development process. 


4. 1 Framework Resource Definitions 


As documented in the Framework Processor Design Document [FPP 91b], 
definition of certain information relevant to the framework must be 
provided. This definition involves identifying the user roles, tools, methods, 
and artifacts that will be referenced at various points in the framework 
specification. The following subsections identify the resources that will be 
referenced by the demonstration framework. 

4.1.1 Roles 


Below are the user roles that participate in the development process defined 
in the demonstration framework. 


Customer/Sponsor 
Project Leader 
Project Administrator 
Technical Administrator 
Technical Analyst 
System Analyst 
Subsystem Designer 
Integration Coder 
Verification Tester 
Field Tester 

Quality Assurance Specialist 
End User Manager 


Project Manager 

Group Leader 

Financial Administrator 

Configuration Control Administrator 

Technical Support Analyst 

System Designer 

Development Coder 

Maintenance Coder 

Validation Tester 

Quality Assurance Tester 

End User 

Customer Service 


4.1.2 Tools 


Below are the candidate tools that can be used at various stages in the 
development process. 

Management Tools 

MS Project 
Excel 

Construction Tools 

Emacs C++ C 

Lex Yacc Motif 

Lint X Windows MS Word 


Lucid Lisp 
dbx 

MacDraw Pro 


Demonstration Framework 


Framework Activity Definition 


22 

MS Draw Micrografix Excel Lotus 123 

Designer 

ObjectVision 
Design Tools 
AI4 

Knowledgeware 
Programmer’s Workbench 
Validation Prototyper 

Database Design Tools 

AI1X 

Modeling Tools 

AIO 
All 
AI3 
IDefine 

4.1.3 Methods 

Below are the candidate methods that can be used during the development 
process. 

EDEFO 
IDEF1X 
IDEF4 
IDEF8 

Structure Charts 

Jackson System Development 
Gantt Charts 
Decision Tables 
Cost Analysis 

4.1.4 Artifacts 

Below are the artifacts produced and manipulated during the development 
process. The column on the right indicates the Data Item Description 
(DID) that applies the each artifact. 

Phase Artifact DID 

A&D Acceptance Test Results SMAP-DID-A200 

A&D Discrepancy Reports SMAP-DID-R004 

A&D Engineering Change Proposals SMAP-DID-R005 

A&D Information System Post-Acceptance Test SMAP-DID-POOO-SY 

A&D Lessons Learned SMAP-DID-R006 


EDEF1 

IDEF3 

IDEF5 

Business Systems Planning (BSP) 
Structured Analysis / Structured 
Design 

Structured Programming 
Decision Trees 
Flow Charts 
Statistical Analysis 
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A&D Performance/Metrics Reports 
A&D Plan Updates 

A&D QA Specs, Procs, Criteria, & Results 

A&D QEA Specs, Procs, Criteria, & Results 

A&D Review Reports 

A&D SA Specs, Procs, Criteria, & Results 

A&D SPA Specs, Procs, Criteria, & Results 

A&D Status Reports 

A&D Training Materials update 

A&D User's Guide update 

A&D Ver. & Val. Results 

A&D Version Description update 

C&I Acquisition Plan 

C&I Concept Document 

C&I Quality Assurance 

C&I Lessons Learned 

C&I Review Reports 

C&I Status Reports 

DES Acceptance Test Procedures & Criteria 

DES Design Specification 

DES Discrepancy Reports 

DES Engineering Change Proposals 

DES Integration Test Specs, Procs, & Criteria 

DES Lessons Learned 

DES Performance/Metrics Reports 

DES Plan Updates 

DES QA Specs, Procs, Criteria, & Results 

DES QEA Specs, Procs, Criteria, & Results 
DES Review Reports 

DES SA Specs, Procs, Criteria, & Results 

DES SPA Specs, Procs, Criteria, & Results 
DES Status Reports 

DES Val. Specs, Procs, Criteria, & Results 

DES Ver. Specs, Procs, Criteria, & Results 

I&T Discrepancy Reports 

I&T Engineering Change Proposals 

I&T Information System Post-Integration Tests 

I&T Integration Test Results 

I&T Lessons Learned 

I&T Maintenance Manual 

I&T Performance/Metric Reports 

I&T Plan Updates 

I&T QA Specs, Procs, Criteria, & Results 

I&T QEA Specs, Procs, Criteria, & Results 

I&T Review Reports 

I&T SA Specs, Procs, Criteria, & Results 

I&T SPA Specs, Procs, Criteria, & Results 

I&T Status Reports 

I&T Training Materials 


SMAP-DID-R007 
SMAP-DID-MOOO-SY 
SMAP-DID-A100 
SMAP-DID-A300 
SMAP-DID-R008 
SMAP-DID-A400 
SMAP-DID-A500 
SMAP-DID-R007 
SMAP-DID-POOO-SY 
SMAP-DID-P500 
SMAP-DID-A600 
SMAP-DID-P400 
SMAP-DID-M100-SY 
SMAP-DID-P100 
SMAP-DID-A100 
SMAP-DID-R006 
SMAP-DID-R008 
SMAP-DID-R007 
SMAP-DID-A200 
SMAP-DID-P300-SY 
SMAP-DID-R004 
SMAP-DID-R005 
SMAP-DID-A200 
SMAP-DID-R006 
SMAP-DID-R007 
SMAP-DID-MOOO-SY 
SMAP-DID-A100 
SMAP-DID-A300 
SMAP-DID-R008 
SMAP-DID-A400 
SMAP-DID-A500 
SMAP-DID-R007 
SMAP-DID-A600 
SMAP-DID-A600 
SMAP-DID-R004 
SMAP-DID-R005 
SMAP-DID-POOO-SY 
SMAP-DID-A200 
SMAP-DED-R006 
SMAP-DID-P600-SY 
SMAP-DID-R007 
SMAP-DID-MOO-SY 
SMAP-DID-A100 
SMAP-DID-A300 
SMAP-DID-R008 
SMAP-D ID- A4 00 
SMAP-DID-A500 
SMAP-DID-R007 
SMAP-DID-POOO-SY 
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I&T User's Guide 

I&T Ver. Specs, Procs, Criteria, & Results 
I&T Version Description Document 
IMPC Acceptance Test Cases 
IMPC Discrepancy Reports 
IMPC Engineering Change Proposals 
IMPC Integration Test Procs, Criteria, & Cases 
IMPC Lessons Learned 
IMPC Performance/Metrics Reports 
IMPC Plan Updates 

IMPC QA Specs, Procs, Criteria, & Results 

IMPC QEA Specs, Procs, Criteria, & Results 

IMPC Review Reports 

IMPC SA Specs, Procs, Criteria, & Results 

IMPC SPA Specs, Procs, Criteria, & Results 

IMPC Status Reports 

IMPC Updates 

IMPC Val. Specs, Procs, Criteria, & Results 

IMPC Ver. Specs, Procs, Criteria, & Results 

RQTS Acceptance Test Specifications 

RQTS Development Plan 

RQTS Discrepancy Reports 

RQTS Engineering Change Proposals 

RQTS Evolutionary Acquisition Plan 

RQTS Independent Val. & Ver. Plan 

RQTS Lessons Learned 

RQTS Performance/Metric Reports 

RQTS Preliminary User's Guide 

RQTS Procurement Package 

RQTS QA Specs, Procs, Criteria, & Results 

RQTS QEA Specs, Procs, Criteria, & Results 

RQTS Requirements Specification 

RQTS Review Reports 

RQTS SA Specs, Procs, Criteria, & Results 

RQTS SPA Specs, Procs, Criteria, & Results 

RQTS Status Reports 

RQTS Sustaining Engineering & Operations Plan 
RQTS Val. Specs, Procs, Criteria, & Results 
RQTS Ver. Specs, Procs, Criteria, & Results 
SEX) Discrepancy Reports 
SEO Engineering Change Proposals 

SEX) Performance/Metrics Reports 

SEX) Review Reports 
SEX) Status Reports 
SEO Updates 
SEO Updates 
SEO Updates 


SMAP-DID-P500 

SMAP-DID-A600 

SMAP-DID-P400 

SMAP-DID-A200 

SMAP-DID-R004 

SMAP-DID-R005 

SMAP-DID-A200 

SMAP-DID-R006 

SMAP-DED-R007 

SMAP-DID-MOOO-SY 

SMAP-DID-A100 

SMAP-DID-A300 

SMAP-DID-R008 

SMAP-DID-A400 

SMAP-DID-A500 

SMAP-DID-R007 

SMAP-DID-POOO-SY 

SMAP-DID-A600 

SMAP-DID-A600 

SMAP-DID-A200 

SMAP-DID-M200-SY 

SMAP-DID-R004 

SMAP-DID-R005 

SMAP-DID-M400-SY 

SMAP-DID-M936 

SMAP-DID-R006 

SMAP-DID-R007 

SMAP-DID-P500 

SMAP-DID- 

SMAP-DID-A100 

SMAP-DID-A300 

SMAP-DID-P200-SY 

SMAP-DID-R008 

SMAP-DID-A400 

SMAP-DID-A500 

SMAP-DID-R007 

SMAP-DID-M300 

SMAP-DID-A600 

SMAP-DID-A600 

SMAP-DED-R004 

SMAP-DID-R005 

SMAP-DID-R007 

SMAP-DED-R008 

SMAP-DID-R007 

SMAP-DID-AOOO-SY 

SMAP-DID-MOOO-SY 

SMAP-DID-POOO-SY 
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Phase Abbreviations 


A&D 

Acceptance & Delivery 

C&I 

Concept & Initiation 

DES 

Design 

I&T 

Integration & Test 

IMPC 

Implementation Coordination 

RQTS 

Requirements 

SEO 

Sustaining Engineering & Operations 


Artifact Abbreviations 


SA 

SPA 

Val 

Ver 

QA 

QEA 

Procs 

Specs 


Safety Assurance 

Security & Privacy Assurance 

Validation 

Verification 

Quality Assurance 

Quality Engineering Assurance 

Procedures 

Specifications 
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4 2 Framework Processes Definition 

The following is a breakdown of the Demonstration Framework based 
partly on the SMAP Documents. Normally, the framework is in an 
electronic form and is much easier to view and explore. However, for 
inclusion in this document, an alternate structure was required. In the 
following section, the UOBs are listed linearly, although they are not 
always so in the actual process model. The descriptions of these UOBs 
should be read in conjunction with Volume II of this document, where the 
actual process model is given. The UOB descriptions in this section are 
listed in roughly the same order as they occur in the process descriptions in 
Volume II. 

Each UOB is described briefly as to what process is represented by the UOB. 
For UOBs which are the leaf nodes of the model (i.e., UOBs which do not 
have a decomposition), a table is given which defines the user roles, 
artifacts, methods, and tools which are affected by that particular UOB. In 
the electronic form, a UOB which has a decomposition actually contains all 
of the user roles, artifacts, methods, and tools from the lower level UOBs 
within its decomposition. The framework processor can easily collect this 
information from the leaf nodes and roll up the sets to the higher level. 
This was not done in this report because the collections of objects becomes 
confusing at the highest levels. Therefore, only the leaf nodes have the role, 
artifact, method, and tool information. Furthermore, following each table 
is the completion criteria that will be used to determine when a UOB is 
considered finished. 

1 Perform Information System Concept & Initiation 

The software development process begins with the Concept & Initiation 
Phase. This phase’s objectives are to determine the feasibility of the project 
and, if feasible, to set in place the assurance and management plans. Also, 
the initial ideas are flushed out and reviewed before proceeding to define the 
requirements for the system. 

2 Develop Information System Requirements 

The second major phase is the requirements definition phase. At this point 
the general concepts have been determined and what is needed is formal 
requirements for the system. In addition, decisions are made as to 
acquiring the system. If procurement is selected, then steps are taken to 
procure the system, as well as verification and validation, from 
independent sources. The development process is documented and 
mechanisms for controlling risk and management issues are placed in 
effect, which is exactly what the FPP is designed to help automate. 

3 Design Information System 

In this phase, the third major phase, the design of the information system 
is created. This is a crucial phase as most errors are introduced in the 
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design and not found until much later. For this reason, the design is 
reviewed thoroughly during the execution of this process. 

4 Coordinate Information System Implementation 

This process begins the actual implementation of the information system. 
The lower level subsystems and components of the whole system begin their 
lifecycles at this time. The pieces of the system are tested and brought 
together to form the finished system. The next stage is begun when the 
subcomponents are linked together. 

5 Integrate & Test Information System Components 

This stage of development begins the testing of the components as well as 
the testing of the system as a whole. Any problems with the coordination of 
the subsystems are investigated and resolved during this stage of 
development. 

6 Deliver Information System 

This stage prepares the system for delivery to the customer/sponsor. Final 
reviews are conducted and the system is installed at the site. The system 
now moves into the maintenance stage. 

7 Maintain Information System 

After the system is put into everyday use, this stage begins. Any changes 
and updates are performed during the Maintenance Phase. When the 
system has been modified, some or all of the previous stages must be 
repeated. In addition, this stage also has steps to determine if the system 
should be retired and an improved system built to replace it. 

Decomposition: Perform Information System Concept & 
Initiation 

1 . 1 Conduct Feasibility Study 

The first step in system development is to conduct a feasibility study. The 
following table shows the agents involved. 
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Artifacts 

User Roles 

Tools 

Methods 

C&I Concept 
Document 

System Analyst 

MS Word 

EDEFO 

C&I Lessons 

Customer/ 

Sponsor 

MS Draw 

JDEF1 

Learned 
C&I Review 

End User 

MacDraw Pro 
MicroGraphix 

IDEF3 

Reports 

C&I Status 
Reports 

End User 

Manager 

Designer 

AIO 

All 

AI3 



Completion: Sign-off by Customer/Sponsor. 
1.2 Compile User Requirements 


To build a system that is to be effective, the user’s needs and requirements 
must be recorded and analyzed. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Concept 
Document 

System Analyst 

Customer/ 

Sponsor 

End User 

End User 

Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

All 

AI3 

Critical Success 
Factors 

Business Area 
Analysis 

IDEFO 

IDEF1 

IDEF3 


Completion: Sign-off by System Analyst and Customer/Sponsor. 


1.3 Define Operational Scenarios 

The process of using the system must be defined so that the final software 
system will match the needs and solve the problems that it is intended to 
solve. 
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Artifacts 

User Roles 

Tools 

Methods 

C&I Concept 
Document 

System Analyst 

Customer/ 

Sponsor 

End User 

End User 

Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AI3 

IDEF3 


Completion: Sign-off by System Analyst and Customer/Sponsor. 


1.4 Develop Management Strategy & Constraints 

This process is where the basic management plans are defined, as well as 
any plans for procurement. 

1.5 Define Assurance Strategy 

Plans and procedures for assuring the quality of the system are developed 
and documented in this process. 

1.6 Define System Concept & Scope 

The first steps toward defining the system are conducted during the system 
concept and scope process. The table following lists the agents involved 
with this process. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Concept 
Document 

System Analyst 

Customer/ 

Sponsor 

End User 

End User 

Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

IDEFO 


Completion: Sign-off by System Analyst and Customer/Sponsor. 
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1.7 Document Results 

The results of the concept and scope process are documented during this 
step for future reference. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Concept 
Document 

System Analyst 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Concept Document is in state Completed. 


Decomposition: Define Assurance Strategy 


1.4.1 Define Assurance Process Requirements 

Like the define development process requirements, this process defines the 
assurance processes that are to be used during the system development. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Quality 

Configuration 

MS Word 

IDEF3 

Assurance 

Control 

Administrator 

MS Draw 



Quality 

Assurance 

MacDraw Pro 



Specialist 

MicroGraphix 

Designer 



Technical 

Administrator 

AI3 



Customer/ 

Sponsor 




System Analyst 




Completion: Sign-off by Technical Administrator and Customer/Sponsor. 


Framework Activity Definition 


Demonstration Framework 














31 


1.4.2 Define Assurance Plan 

In this process, the Assurance Plan is defined. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Configuration 

MS Word 

IDEFO 

Specification 

Control 

Administrator 

MS Draw 



Quality 

Assurance 

MacDraw Pro 



Specialist 

MicroGraphix 

Designer 



Technical 

Administrator 

AIO 



Customer/ 

Sponsor 




System Analyst 




Completion: Sign-off by Technical Administrator and Customer/Sponsor. 

1.4.3 Document Assurance Plan 

In this process, the Assurance Plan is documented. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Quality 
Assurance 

System Analyst 

MS Word 




MS Draw 


SMAP-DID- 

A100 


MacDraw Pro 


Assurance 


MicroGraphix 


Specification 


Designer 


SMAP-DID- 

A000-SY 





Completion: Artifact Assurance Specification is in state Completed. 

Decomposition: Develop Management Strategy & Constraints 

1.5.1 Perform Tracking Activities 

Throughout the life cycle of the system, the development activities are 
closely tracked to insure the quality of the final product. 


Demonstration Framework 


Framework Activity Definition 
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1.5.2 Conduct Procurement Activities 

If the system is to be procured or if the verification and validation is to be 
procured, then this process is performed. 


Artifacts 

User Roles 

Tools 

Methods 

C&I 

Acquisition 

Plan 

Technical 

Administrator 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 



Completion: Sign-off by Technical A dmi nistrator. 

1.5.3 Define Activities of the Acquirer 

The purpose of any software system is to assist the users of the system in 
doing their jobs more efficiently. The activities of the enterprise must be 
properly modeled if their is any hope of the system solving the problems it is 
intended to solve. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Technical 

Administrator 

System Analyst 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 

Auto SADT 
IDefine 

IDEFO 

EDEF3 


Completion: Sign-off by Technical Administrator. 


Framework Activity Definition 


Demonstration Framework 
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1.5.4 Define Structure of the Acquirer 

To structure a system for a particular organization, the structure of the 
enterprise acquiring the software must be defined. This process defines 
and documents the structure of the sponsor for the system. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Technical 

Administrator 

System Analyst 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

All 

AI1X 

IDEF1 

IDEFIX 


Completion: Sign-off by Technical Administrator. 

1.5.5 Define Development Process Requirements 

The requirements for the actual development of the system are documented 
in the Management Plan during this process. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Technical 

MS Word 

IDEF3 

Plan 

Administrator 

MS Draw 



System Analyst 

MacDraw Pro 




MicroGraphix 

Designer 




AI3 



Completion: Sign-off by Technical Administrator. 


Demonstration Framework 


Framework Activity Definition 
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1.5.6 Define Management Plan 

The management of the system development is outlined and recorded 
during this process. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Technical 

Administrator 

System Analyst 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 

MS Project 

IDEFO 

EDEF3 


Completion: Sign-off by Technical Administrator. 

Decomposition: Perform Ticking Activities 

1.5. 1.1 Specify Reviews 

Tracking Activities are managed by specifying and documenting how the 
reviews should be organized. This step handles the specification of the 
reviews. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Quality 
Assurance 

C&I Lessons 
Learned 

C&I Review 
Reports 

C&I Status 
Reports 

Technical 

Administrator 

Configuration 

Control 

Administrator 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

MS Project 



Completion: Sign-off by Technical Administrator. 


Framework Activity Definition 


Demonstration Framework 
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1.5. 1.2 Conduct Reviews 


In this process, the reviews are actually carried out. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Quality 
Assurance 

C&I Lessons 
Learned 

C&I Review 
Reports 

C&I Status 
Reports 

Technical 

Administrator 

System Analyst 

Customer/ 

Sponsor 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Technical Administrator and Customer/Sponsor. 


1. 5.1.3 Document Reviews 


After a review has been conducted, the results are recorded in the 
appropriate artifacts. 


Artifacts 

User Roles 

Tools 

Methods 

C&I Quality 

Technical 

MS Word 


Assurance 

Administrator 

MS Draw 


C&I Lessons 
Learned 


MacDraw Pro 


C&I Review 


MicroGraphix 


Reports 


Designer 


C&I Status 
Reports 





Completion: Artifact Quality Assurance is in state Completed. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition: Develop Information System Requirements 

2. 1 Establish Risk & Management Control Mechanisms 

This process is conducted to establish mechanisms which will insure the 
quality of the final system throughout the development process. 

2.2 Procure Development of System 

If the system or verification and validation are to be procured, then this 
process is performed. Otherwise, it is skipped. 

2^ Define Development Processes 

All activities performed by the provider of the information system are 
defined and documented in this process. 

2.4 Perform Requirements Analysis 

The processes to support the requirements definition are done in this 
process. 

2.5 Decide Whether to Proceed 

The decision to continue to the next phase or to repeat steps in this phase is 
made at this point. 

Decomposition: Establish Risk & Management Control 

Mechanisms 

2.1.1 Collect & Document Metric Information 

In this process, the metric information that is used to track the 
performance of the system is collected and documented. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Performance/ 

System Analyst 

MS Word 


Metric Reports 

Verification 

MacDraw Pro 


Tester 

MicroGraphix 




Validation Tester 

Designer 



Field Tester 

Test Tools 


- 

Quality 

Assurance Tester 




Completion: Artifact Performance/Metric Reports is in state Completed. 


Framework Activity Definition 


Demonstration Framework 








37 


t . 

2.1.2 Develop & Document Acceptance Test Specification 

The specifications for accepting or rejecting the system are defined and 
recorded. \ 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Acceptance 

Test 

Specifications 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Acceptance Test Specifications is in state Completed. 

2.1.3 Review Assurance Specifications 

After the assurance specifications are developed, they are reviewed in this 
process to insure the quality of the final system. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Specification 

RQTS Review 
Reports 

Technical 

Analyst 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Technical Analyst. 

2.1.4 Prepare Discrepancy & Deficiency Reports 

Any discrepancies or deficiencies found during the review are documented 
in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Discrepancy 

Reports 

System Analyst 

Technical 

Analyst 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Technical Analyst. 


Demonstration Framework 


Framework Activity Definition 
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2.1.5 Document Reviews 

In the Document Reviews process, documents are examined and 
evaluations are recorded in the review reports. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Review 
Reports 

Technical 

Analyst 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

System Analyst 

Verification 

Tester 

Validation Tester 
Field Tester 
Quality 

Assurance Tester 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Review Reports is in state Completed. 

2.1.6 Conduct Verification Activities 

In this process, V&V activities are conducted to insure the quality of the 
final product. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition: Conduct Verification Activities 

2. 1 .6. 1 Define Validation Specifications 

The specifications for validating the information system are defined during 
this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Val. 
Specs, Procs, 
Criteria, & 
Results 

Validation 
Specifications, 
Procedures, 
Criteria, & 
Results 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Quality Assurance Specialist. 

2. 1.6.2 Procure Independent V&V 

If independent V&V is requested, this process is performed to procure it. 

2.1 .6.3 Develop Verification Activities 

The specifications for verifying the information system are produced in this 
process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Ver. 
Specs, Procs, 
Criteria, & 
Results 

Verification 
Specifications, 
Procedures, 
Criteria, and 
Results 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

Gantt Charts 
IDEFO 


Completion: Sign-off by Quality Assurance Specialist. 


Demonstration Framework 


Framework Activity Definition 
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2.1.6.4 Document Expected V&V Results 

In this process, the expected results from the V&V activities are recorded 
for comparison with the actual results later in the development process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Val. 

Quality 

MS Word 


Specs, Procs, 
Criteria, & 

Assurance Tester 

MacDraw Pro 


Results 

Quality 

Assurance 

MicroGraphix 


Validation 

Specialist 

Designer 


Specifications, 

Procedures, 

Verification 

Test Tools 


Criteria, & 
Results 

Tester 



RQTS Ver. 
Specs, Procs, 
Criteria, & 

Validation Tester 



Results 




Verification 




Specifications, 

Procedures, 




Criteria, and 
Results 





Completion: Artifacts are in state Completed. 
2.1.6.5 Assign Resolution Responsibility 


Assignments are given to the individuals who are responsible for the 
resolution of discrepancies and deficiencies. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Engineering 

Change 

Proposals 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition; Procure Independent V&V 

* 

2. 1.6.2. 1 Define V&V Approach 

The plans for verification and validation of the system are outlined in this 
process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Val. 
Specs, Procs, 
Criteria, & 
Results 

Validation 
Specifications, 
Procedures, 
Criteria, & 
Results 

RQTS Ver. 
Specs, Procs, 
Criteria, & 
Results 

Verification 
Specifications, 
Procedures, 
Criteria, and 
Results 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

Gantt Charts 
IDEFO 


Completion: Sign-off by Quality Assurance Specialist. 


Demonstration Framework 


Framework Activity Definition 
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2. 1.6.2. 2 Define V&V Methods 

If new methods are needed for the V&V activities, they are defined in this 
activity. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Val. 
Specs, Procs, 
Criteria, & 
Results 

Validation 
Specifications, 
Procedures, 
Criteria, & 
Results 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

IDEFO 

RQTS Ver. 
Specs, Procs, 
Criteria, & 
Results 




Verification 
Specifications, 
Procedures, 
Criteria, and 
Results 





Completion: Sign-off by Quality Assurance Specialist. 


Framework Activity Definition 


Demonstration Framework 
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2. 1.6. 2. 3 Document in V&V Plan 

V&V approaches and methods are documented in the V&V plan at this 
point in the development. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Val. 
Specs, Procs, 
Criteria, & 
Results 

Validation 
Specifications, 
Procedures, 
Criteria, & 
Results 

RQTS Ver. 
Specs, Procs, 
Criteria, & 
Results 

Verification 
Specifications, 
Procedures, 
Criteria, and 
Results 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifacts are in state Completed. 


Decomposition: Procure Development of System 

2.2.1 Prepare RFP 

The RFP is prepared in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Procurement 

Package 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Procurement Package is in state Completed. 


Demonstration Framework 


Framework Activity Definition 
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2.2.2 Prepare SOW 

If the system is to be procured from external sources, then the SOW is 
prepared at this point. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Procurement 

Package 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Procurement Package is in state InProgress. 

2.2.3 Evaluate Source 

The sources for the procurement of the system are evaluated to determine 
the best source. 



User Roles 

Tools 

Methods 

RQTS Review 
Reports 

Customer/ 

Sponsor 

Project Manager 

Project Leader 

Technical 

Analyst 

System Analyst 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 



Completion: Sign-off by Technical Analyst and System Analyst. 


Framework Activity Definition 


Demonstration Framework 
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2.2.4 Select Source 


The source for the development is selected in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Procurement 

Package 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 


2.2.5 Negotiate Contract 


The contract is negotiated and development is started in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Procurement 

Package 

Project 

Administrator 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Project Administrator. 


Decomposition: Define Development Processes 

2.3.1 Define New Procedures & Standards 

Any new procedures or standards that are necessary for development are 
determined at this point. 


Demonstration Framework 


Framework Activity Definition 
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2.3.2 Define Sustaining Engineering Processes 

The processes for maintaining the information system are defined and 
documented in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 
Sustaining 
Engineering & 
Operations 
Plan 

Project Manager 

System Analyst 

Technical 

Administrator 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 

IDEFO 

IDEF3 


Completion: Sign-off by Project Manager. 


2.3.3 Identify Approach 

The first process which must be done in defining the development process 
is to determine the approach to be taken. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Specification 

Management 
Control & 

Status Reports 

Management 

Plan 

Project Manager 

Project Leader 

Group Leader 

Technical 
Support Analyst 

System Analyst 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Framework Activity Definition 


Demonstration Framework 
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Completion: Sign-off by Project Manager. 

2.3.4 Define Methods for Activities 

In this process, the methods to be used are documented. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Configuration 

Control 

Administrator 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 



Completion: Sign-off by Configuration Control Administrator. 

2.3.5 NOP 

Due to the limitations of the IDEF3 tool used to create this framework, 
occasionally a NOP UOB is introduced into the model to indicate a branch 
in which nothing happens. 

2.3.6 Define Incremental Development Processes 

If incremental development is specified in the Management Plan, this 
process is conducted. 

2.3.7 Review Management Plan 

At this time, the management plans are reviewed and evaluated. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Customer/ 

MS Word 


Plan 

Sponsor 

MacDraw Pro 



End User 

Manager 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition: Define New Procedures & Standards 

2.3.1. 1 Develop Standards 

If new standards are required to perform the development of the system, 
those standards are defined in this process. 



User Roles 

Tools 

Methods 

RQTS 

Requirements 

Specification 

System Analyst 

System Designer 

Subsystem 

Designer 

Development 

Coder 

Technical 

Administrator 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Technical Administrator. 

2.3. 1.2 Develop Procedures 

If new procedures are required for the implementation of the system, they 
are developed in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

System Analyst 

MS Word 

IDEFO 

Specification 

System Designer 

MacDraw Pro 

IDEF3 


Subsystem 

MicroGraphix 



Designer 

Designer 



Development 

AIO 



Coder 

AI3 



Technical 

Administrator 




Completion: Sign-off by Technical Administrator. 


Framework Activity Definition 


Demonstration Framework 
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2.3. 1.3 Document New Procedures and Standards 

This process is conducted after the new procedures or standards are 
defined. 


Artifacts 


RQTS QA 

Specs, Procs, 
Criteria, & 
Results 

RQTS QEA 
Specs, Procs, 
Criteria, & 
Results 

RQTS SA 

Specs, Procs, 
Criteria, & 
Results 

Safety 

Assurance 

Specifications, 

Procedures, 

Criteria, and 

Results 

RQTS SPA 
Specs, Procs, 
Criteria, & 
Results 

Security and 

Privacy 

Assurance 

Specifications, 

Procedures, 

Criteria, and 

Results 


User Roles 

System Analyst 

System Designer 

Subsystem 

Designer 

Development 

Coder 

Project 

Administrator 

Customer/ 

Sponsor 

Project Manager 


Tools 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifacts are in state Completed. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition: Define Incremental Development Processes 

2.3.6. 1 Define Specific Increments 

This process is only conducted if the system is to be an incremental delivery 
system. At this time the specific increments are delineated in the 
Evolutionary Acquisition Plan. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Project Manager 

MS Word 

IDEFO 

Evolutionary 

Acquisition 

Technical 

MacDraw Pro 

IDEF3 

Plan 

Administrator 

MicroGraphix 



System Analyst 

Designer 




AI0 




AI3 



Completion: Sign-off by Customer/Sponsor. 

2 .3.6.2 Prioritize Approach 

The development of the various increments defined in the previous step are 
prioritized in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Evolutionary 

Acquisition 

Plan 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Gantt Charts 

Business 

Systems 

Planning 


Completion: Sign-off by Customer/Sponsor. 


Framework Activity Definition 


Demonstration Framework 
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2 .3.6.3 Document Incremental Processes 


The plans for developing the information system in incremental steps are 
documented in the Evolutionary Acquisition Plan in this activity. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Evolutionary 

Acquisition 

Plan 

Project Manager 

Technical 

Administrator 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Gantt Charts 

Completion: Artifact Evolutionary Acquisition Plan is in state Completed. 
Decomposition: Perform Requirements Analysis 
2.4. 1 Develop User Scenarios 

Each possible user scenario is recorded and evaluated in 

this process. 

Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

Specification 

System Analyst 

End User 

End User 

Manager 

System Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AI3 

Knowledgeware 

SymMod 

IDEF3 


Completion: Sign-off by System Analyst. 


Demonstration Framework 


Framework Activity Definition 
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2.4.2 Investigate User Needs 

In this process, the user’s needs are evaluated to specify the requirements 
that are to be met in the final implementation. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

System Analyst 

MS Word 

IDEFO 

Specification 

End User 

MacDraw Pro 

IDEF1 


End User 

Manager 

MicroGraphix 

Designer 

AIO 

All 

AI3 

IDEF3 


Completion: Sign-off by System Analyst. 


2.4.3 Prototype System 


As a way of providing a proof of concept, a prototype of the system is created 
in this process. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Discrepancy 

Reports 

RQTS 

Engineering 

Change 

Proposals 

System Designer 

Subsystem 

Designer 

Development 

Coder 

Emacs 

C++ 

Motif 

dbx 

X Windows 

ObjectVision 

Knowledgeware 

Structured 

Programming 



Validation 
Proto typer 




AI1X 



Completion: Sign-off by System Designer. 


Framework Activity Definition 


Demonstration Framework 
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2.4.4 Evaluate External Interface 

After the external interfaces are defined, they are evaluated to insure that 
the end user will be satisfied. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

Specification 

System Designer 

End User 

End User 

Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

ObjectVision 



Completion: Sign-off by System Designer and End User. 


2.4.5 Define External Interface 


This process is performed to define the external interfaces to the 
information system. A process that is as important as the design of the 
internal components of the system. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

Specification 

System Designer 
End User 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AI3 

IDEF3 

EDEF8 


Completion: Sign-off by System Designer. 


Demonstration Framework 


Framework Activity Definition 
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2.4.6 Analyze Requirements 


The requirements are examined for correctness in this activity. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

Specification 

Project Manager 
Project Leader 
Group Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 



Completion: Sign-off by Project Manager. 


2.4.7 Synthesize Requirements 

In the process, the actual requirements for the information system are 
defined. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

Customer/ 

Sponsor 

MS Word 

IDEFO 

Specification 

Project Manager 

MacDraw Pro 

IDEF1 


Project Leader 
System Analyst 
System Designer 

MicroGraphix 

Designer 

AIO 

All 

AI1X 

AI3 

IDEF1X 

IDEF3 


Completion: Sign-off by Customer/Sponsor. 


Framework Activity Definition 


Demonstration Framework 
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2.4.8 Partition Requirements into Increments 

If the system is to be delivered in incremental steps, then the requirements 
are partitioned in to the various increments during this step. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Status 
Reports 

RQTS Review 
Reports 

RQTS 

Evolutionary 

Acquisition 

Plan 

RQTS Lessons 
Learned 

Project Manager 
Project Leader 
Group Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Gantt Charts 


Completion: Sign-off by Project Manager. 


2.2.9 Review Requirements Changes 

After the requirements are examined, any changes must be reviewed before 
the modifications are made to the requirements documents. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Status 
Reports 

RQTS Review 
Reports 

RQTS Lessons 
Learned 

Project Manager 
Project Leader 
Group Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition; Decide Whether to Proceed 

2.5. 1 Review Requirements of Product Specification 


After the requirements for the information system have been completed, 
they are reviewed in this step of the development. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Requirements 

Specification 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor and Project Manager. 


2.5.2 Evaluate Requirements Review & Status Reports 

All review and status reports are evaluated to prepare for moving to the 
next stage in the development lifecycle. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS Status 
Reports 

RQTS Review 
Reports 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor and Project Manager. 


Framework Activity Definition 


Demonstration Framework 
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2.5.3 Document Results 

The results of all requirement activities are documented at this time. 


Artifacts 

User Roles 

Tools 

Methods 

RQTS 

Discrepancy 

Reports 

Project Manager 
Project Leader 

MS Word 
MacDraw Pro 


RQTS 

Engineering 

Change 

Proposals 

Quality 

Assurance 

Specialist 

MicroGraphix 

Designer 


RQTS Lessons 
Learned 




RQTS 

Performance/ 
Metric Reports 





Completion: Artifacts are in state Completed. 

I t 

Decomposition: Design Information System 

3.1 Manage Design Phase 

During this step of the design phase all management activities are carried 
out. 

3.2 Conduct Engineering Design 

The actual design steps are performed during this process of the 
development. 

3.3 Conduct Risk & Management Control Activities 

While the other activities of the design are being performed, this process 
makes certain that the development is proceeding without introducing 
errors into the system. 

3.4 Decide Whether To Proceed 

After the design has been created, reviews are conducted in this step. 
Acceptance or rejection of the design is made after the products of this 
phase are evaluated. If the design is acceptable, the development proceeds 
to the next stage. If not, the design steps are repeated until an acceptable 
design is reached. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition; Manage Design Phase 

3.1.1 Evaluate Metric Information 


In this process, the metrics for measuring the status of the information 
system is evaluated. This information is used for tracking and modifying 
the resource estimation. 


Artifacts 

User Roles 

Tools 

Methods 

DES 

Performance/ 

Metrics 

Reports 

Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Project Leader. 


3.1.2 Re-evaluate Risk Areas 


Risk areas are re-evaluated as directed by the management plan, to 
determine what planning modifications are needed. 


Artifacts 

User Roles 

Tools 

Methods 

DES Lessons 
Learned 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Project Manager. 


Framework Activity Definition 


Demonstration Framework 



















$ 
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3.1.3 Modify & Update Plans 

Modifications and updates to the plans are made as suggested by the 
previous process. 


Artifacts 

User Roles 

Tools 

Methods 

DES Plan 

Updates 

Project Manager 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Plan Updates is in state Completed. 

3. 1.4 Conduct Procurement & Selection Process 
This process is conducted only if the entire system is to be procured. 
Decomposition: Conduct Procurement & Selection Process 
3. 1 .4. 1 Initiate Identification Process 

The identification of suitable off-the-shelf information systems is performed 
in this step. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Project 

Administrator 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Decision Tables 


Completion: Sign-off by Project Administrator. 


Demonstration Framework 


Framework Activity Definition 
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3. 1.4.2 Initiate Evaluation Process 


An evaluation of the suitable information systems is conducted. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Project 

Administrator 
System Analyst 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Decision Tables 


Completion: Sign-off by Project Administrator. 


3. 1.4.3 Initiate Selection Process 


The information system is selected in this process. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Project 

MS Word 


Plan 

Administrator 

MS Draw 



Customer/ 

Sponsor 

MacDraw Pro 



Project Manager 

MicroGraphix 

Designer 



Completion: Sign-off by Project Administrator. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition: Conduct Engineering Design 

3.2.1 Define Interface 


The interface to the information system is defined at this time. 


Artifacts 

User Roles 

Tools 

Methods 

DES Design 
Specification 

System Designer 

Subsystem 

Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AI3 

IDEF8 


Completion: Sign-off by System Designer. 


3.2.2 Define System Architecture 

In this process, the entire system architecture is developed and recorded. 

3.2.3 Allocate Requirements To Subsystems 

The individual requirements for the system are assigned to various 
subsystems in this process. 


Artifacts 

User Roles 

Tools 

Methods 

DES Design 
Specification 

Project Leader 

System Designer 

Subsystem 

Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 



Completion: Sign-off by Project Leader. 


3.2.4 Conduct V&V Activities 

The verification and validation activities that can be performed at this point 
in the development are conducted in this process. 


Demonstration Framework 


. Framework Activity Definition 
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Decomposition: Allocate Requirements To Subsystems 

3.2.2. 1 Develop Requirements Traceability 

Requirements traceability is developed to guarantee an implementation 
that is consistent with the original requirements. 


Artifacts 

User Roles 

Tools 

Methods 

DES Plan 

Updates 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 



Completion: Sign-off by Quality Assurance Specialist. 

3.2. 2.2 Document Requirements Traceability 

The previous step’s information is documented in this process. 


Artifacts 

User Roles 

Tools 

Methods 

DES Plan 

Updates 

Quality 

Assurance Tester 

MS Word 


Quality 

MacDraw Pro 




Assurance 

MicroGraphix 



Specialist 

Designer 



Completion: Artifact Plan Updates is in state InProgress. 


Framework Activity Definition 


Demonstration Framework 
















63 


t 

3.2.2.3 Partition Design into Increments 

If an incremental development approach is used, then the design is 
partitioned into the various increments in this process. 


Artifacts 

User Roles 

Tools 

Methods 

DES Design 
Specification 

System Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Structured 
Analysis/Struct 
ured Design 

Jackson System 
Development 

DSSD(Nassi- 

Shneiderman) 


Completion: Sign-off by System Designer. 

3 .2.2.4 Initiate Integration Test Procedures 

The integration test specification is detailed at this time. 


Artifacts 

User Roles 

Tools 

Methods 

DES 

Integration 
Test Specs, 
Procs, & 

Criteria 

> 

Quality 

Assurance Tester 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 

IDEFO 

IDEF3 


Completion: Sign-off by Quality Assurance Tester. 


Demonstration Framework 


Framework Activity Definition 
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3 .2.2.5 Document Integration Tests 

The integration test specifications developed in the previous step are now 
documented in the integration test specification section of the assurance 
plan. 


Artifacts 

User Roles 

Tools 

Methods 

DES 

Integration 
Test Specs, 
Procs , & 

Criteria 

Quality 

Assurance Tester 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Integration Test Specs, Procs, & Criteria is in state 
Completed. 


Decomposition: Conduct V&V Activities 

3.2.4. 1 Conduct Verification of Design 


The design is verified against the requirements in this procedure. 


Artifacts 

User Roles 

Tools 

Methods 

DES Ver. 

Specs, Procs, 
Criteria, & 
Results 

System Designer 

Subsystem 

Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by System Designer. 

3 .2. 4.2 Document Verification of Design Results 

The results of the design verification are documented in this activity. 


Artifacts 

User Roles 

Tools 

Methods 

DES Ver. 

Specs, Procs, 
Criteria, & 

Results 

System Designer 

Subsystem 

Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Framework Activity Definition 


Demonstration Framework 
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Completion: Artifact Ver. Specs, Procs, Criteria, & Results is in state 
InProgress. ;S 

3.2. 4.3 Develop Validation Procedures 

Validation procedures are defined in this step of the V&V activities process. 


Artifacts 

User Roles 

Tools 

Methods 

DES Val . 

Quality 

MS Word 

IDEFO 

Specs, Procs, 
Criteria, & 

Assurance Tester 

MacDraw Pro 

EDEF3 

Results 

Quality 

Assurance 

MicroGraphix 



Specialist 

Designer 




AIO 




AI3 



Completion: Sign-off by System Designer. 

3 .2.4.4 Develop Validation Criteria 

Validation criteria are defined in this step of the V&V activities process. 


Artifacts 

User Roles 

Tools 

Methods 

DES Val. 

Specs, Procs, 
Criteria, & 
Results 

System Designer 

Subsystem 

Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by System Designer. 


Demonstration Framework 


Framework Activity Definition 
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3 .2.4.5 Document V&V Reports 

Finally, all of the V&V information that has been produced is documented 
in the assurance plan. 


Artifacts 

User Roles 

Tools 

Methods 

DES Val . 

Quality 

MS Word 


Specs, Procs, 
Criteria, & 

Assurance Tester 

MacDraw Pro 


Results 

Quality 

Assurance 

MicroGraphix 


DES Ver. 

Specialist 

Designer 


Specs, Procs, 
Criteria, & 

System Designer 



Results 

Subsystem 

Designer 




Completion: Artifacts are in state Completed. 


Decomposition: Conduct Risk & Management Control Activities 

3.3. 1 Develop & Document Acceptance Test Criteria 


Acceptance test criteria are also developed and documented in this process. 


Artifacts 

User Roles 

Tools 

Methods 

DES QA Specs, 
Procs, Criteria, 
& Results 

DES QEA 

Specs, Procs, 
Criteria, & 
Results 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifacts are in state Completed. 


Framework Activity Definition 


Demonstration Framework 
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3.3.2 Develop & Document Acceptance Test Procedures 

The acceptance test procedures continue with the development of the 
acceptance test section of the assurance specification. 


Artifacts 

User Roles 

Tools 

Methods 

DES 

Acceptance 

Test 

Procedures & 
Criteria 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Acceptance Test Procedures & Criteria is in state 
Completed. 

3.3.3 Collect & Document Metric Information 

Metric information is collected and documented for the tracking and 
evaluation of the information system . 


Artifacts 

User Roles 

Tools 

Methods 

DES 

Performance/ 

Metrics 

Reports 

System Analyst 

System Designer 

Subsystem 

Designer 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Artifact Performance/Metrics Reports is in state Completed. 


Demonstration Framework 


Framework Activity Definition 
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3.2.4 Assign Resolution Responsibility 

Any discrepancies or deficiencies are assigned to individuals for resolution 
during this step. 


Artifacts 

User Roles 

Tools 

Methods 

DES 

Discrepancy 

Reports 

DES 

Engineering 

Change 

Proposals 

Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


Decomposition: Decide Whether To Proceed 

3.4.1 Conduct Reviews 


Reviews of the design documents is conducted at this time. 


Artifacts 

User Roles 

Tools 

Methods 

DES Review 
Reports 

System Analyst 

System Designer 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor and Project Manager. 


Framework Activity Definition 


Demonstration Framework 
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3.4.2 Evaluate Status Reports 


All status reports from the design phase are evaluated to assist in 
determining whether to proceed. 


Artifacts 

User Roles 

Tools 

Methods 

DES Status 
Reports 

System Analyst 

System Designer 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor and Project Manager. 


3.4.3 Evaluate Reviews 


All reviews of the system’s design are evaluated to assist in determining 
whether to start the next phase of development or to repeat some or all of the 
steps of the design. 


Artifacts 

User Roles 

Tools 

Methods 

DES Review 
Reports 

System Analyst 

System Designer 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor and Project Manager. 


Demonstration Framework 


Framework Activity Definition 
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3.4.4 Complete Design Review 

The final design review is conducted before accepting or rejecting the 
design. 


\ Artifacts User Roles 

Tools Methods 

DES Design 
Specification 

DES 

Discrepancy 

Reports 

DES 

Engineering 

Change 

Proposals 

DES Lessons 
Learned 

DES Plan 

Updates 

DES Review 
Reports 

System Analyst 

System Designer 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-ofF by Customer/Sponsor and Project Manager. 

Decomposition; Coordinate Information System Implementation 

4.2 Manage Coordination Phase 

In this process, all of the management planning activities are conducted 
for the coordination of the implementation. 

4. 1 Conduct Risk & Management Control Activities 

Throughout the implementation phase, risk and management control 
processes are performed to insure the quality and make certain the 
development is proceeding according to the plans. 

4.3 Prepare for Integration Test Activities 

During this activity, plans for the testing of the integrated system are 
developed and reviewed. 


Framework Activity Definition 


Demonstration Framework 
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4.4 Review Design of Subsystems and Components 

The lower level components and subsystems are reviewed at this point to 
insure that they will perform as they should. 

45 Initiate Subsystem Lifecycle 

This process is actually a place holder for the Software Component Lifecycle 
Model. When the Information System development reaches this. point, the 
Software Component Lifecycle begins for each major component of the 
Information System. 

46 Coordinate Interaction & Implementation of Components 

After the subsystems are created and tested thoroughly as individual 
components, they are brought together in this process to test for 
incompatibilities between the components. 

47 Decide Whether To Proceed 

As with the previous stages, this process is conducted to determine the 
status of the current implementation and to make the decision to proceed to 
the next stage or repeat some or all of the step in this stage. 

Decomposition: Conduct Risk & Management Control Activities 

4.1.1 Collect Metric Information 

* ' 

Metric information is collected for tracking and evaluating the information 
system. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 

Performance/ 

Metrics 

Reports 

System Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by System Designer. 


Demonstration Framework 


Framework Activity Definition 
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4. 1.2 Document Metric Information 

The metric information collected in the previous step is documented at this 
time. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 

Performance/ 

Metrics 

Reports 

System Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Performance/Metrics Reports is in state Completed. 
4.1.3 Assign Resolution Responsibility 


Any discrepancies or deficiencies are assigned to individuals for resolution 
during this step. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 

Discrepancy 

Reports 

IMPC 

Engineering 

Change 

Proposals 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition; Manage Coordination Phase 

4.2. 1 Evaluate Metric Information 

In this process, the metrics for measuring the status of the information 
system is evaluated. This information is used for tracking and modifying 
the resource estimation. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 

Performance/ 

Metrics 

Reports 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 

4.2.2 Re-evaluate Risk Areas 

Risk areas are re-evaluated as directed by the management plan to 
determine what planning modifications are needed. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Lessons 
Learned 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 


Demonstration Framework 


Framework Activity Definition 
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4.2.3 Modify & Update Plans 


Modifications and updates to the plans are made as suggested by the 
previous process. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Customer/ 

MS Word 


Plan 

Sponsor 

MS Draw 



Project Manager 

MacDraw Pro 




MicroGraphix 

Designer 



Completion: Artifact Management Plan is in state Completed. 


4.2.4 Conduct Final Procurement & Selection 


If the system is to be acquired entirely off-the-shelf, then the final 
procurement and selection is performed at this time. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Project 

Administrator 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Administrator. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition; Prepare for Integration Test Activities 

4.3. 1 Develop Test Cases 


Test cases are defined at this point. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 
Acceptance 
Test Cases 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Test Tools 



Completion: Sign-off by Quality Assurance Specialist. 


4.3.2 Develop Test Criteria 


Criteria for the test results are developed in this step. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC QA 

Specs, Procs, 
Criteria, & 
Results 

IMPC QEA 
Specs, Procs, 
Criteria, . & 
Results 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Test Tools 



Completion: Sign-off by Quality Assurance Specialist. 


Demonstration Framework 


Framework Activity Definition 
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4.3.3 Develop Test Procedures 


In this process, test procedures are defined. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC QA 

Specs, Procs, 
Criteria, & 
Results 

IMPC QEA 
Specs, Procs, 
Criteria, & 
Results 

Quality 

Assurance Tester 

Quality 

Assurance 

Specialist 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 

IDEFO 

EDEF3 


Completion: Sign-off by Quality Assurance Specialist. 


4.3.4 Document Integration Test Procedures, Criteria, & Cases 


The results of the previous activities are documented in the assurance plan 
during this process. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 

Quality 

MS Word 


Integrat. Test 
Procs, Criteria, 

Assurance Tester 

MS Draw 


& Cases 

Quality 

Assurance 

Specialist 

MacDraw Pro 



MicroGraphix 

Designer 




Completion: Artifact Integrat. Test Procs, Criteria, & Cases is in state 
Completed. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition: Review Design of Subsystems and Components 

4.4. 1 Review Lower-level Components 

When the lower-level components are completed, they are reviewed in this 
process. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 
Reports 

System Designer 

Subsystem 

Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by System Designer. 


4.4.2 Conduct Verification of Lower-level Systems 


Verification of lower-level components is conducted at this point in the 
development of the information system. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Ver. 
Specs, Procs, 
Criteria, & 
Results 

Quality 

Assurance Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Test Tools 

• -V 


Completion: Sign-off by Quality Assurance Tester. 


Demonstration Framework 


Framework Activity Definition 
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4.4.3 Document Review Findings 

The results of the reviews of the lower-level components are documented in 
this step. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 
Reports 

System Designer 
Quality 

Assurance Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Review Reports is in state Completed. 
4.4.4 Prepare for Validation 


Preparations are made for the validation of the system are completed in this 
step. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Val. 
Specs, Procs, 
Criteria, & 
Results 

Validation Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Validation Tester. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition: Coordinate Interaction & Implementation of 
Components 

4.6. 1 Review Designs for Subsystems & Components 


The designs for the subsystems are reviewed at this time. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 
Reports 

System Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by System Designer. 


4.6.2 Review Requirements for Subsystems & Components 
The requirements of the subsystems are reviewed at this time. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 
Reports 

SMAP-DID- 

R008 

System Analyst 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by System Analyst. 


Demonstration Framework 


Framework Activity Definition 
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4.6.3 Review Interface Specifications 

The interface specifications for the component systems are reviewed to 
insure that they operate in conjunction with each other as specified. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 
Reports 

Integration 

Coder 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Integration Coder. 
4.6.4 Document Review Findings 


All review findings are recorded in the appropriate sections of the 
documentation for the information system. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Project Manager 

MS Word 



Project Leader 

MS Draw 


Product 

Specification 

MacDraw Pro 



Document 


MicroGraphix 


Assurance 

Specification 


Designer 


Management 
Control & 




Status Reports 





Completion: Artifacts are in state Completed. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition: Decide Whether To Proceed 

4.7.1 Conduct Reviews 


Reviews of the implementation documents are conducted at this time. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 
Reports 

IMPC 

Discrepancy 

Reports 

IMPC Lessons 
Learned 

IMPC Status 
Reports 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 


4.7.2 Evaluate Reviews 


Evaluations of the implementation reviews are performed. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC Review 

Customer/ 

MS Word 


Reports 

Sponsor 

MS Draw 



Project Manager 

MacDraw Pro 



Project Leader 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor. 


Demonstration Framework 


Framework Activity Definition 
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4.7.3 Document All Review Findings 


All review findings are documented in the appropriate plan documents and 
reports. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Specification 

Management 
Control & 

Status Reports 

Management 

Plan 

Product 

Specification 

Document 

Project Manager 
Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifacts are in state Completed. 


4.7.4 Accept or Reject System 

The decision to accept or reject the system is made at this point in the 
implementation phase. 


Artifacts 

User Roles 

Tools 

Methods 

IMPC 

Discrepancy 

Reports 

IMPC Lessons 
Learned 

IMPC Plan 
Updates 

IMPC Updates 

IMPC Status 
Reports 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor. 


Framework Activity Definition 


Demonstration Framework 
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Decomposition: Integrate & Test Information System 

Components 

5.1 Manage Integrate & Test Phase 

During this step of the integrate and test phase, all management activities 
are carried out. 

5.2 Conduct Risk & Management Control Activities 

This process makes certain that the development is proceeding without 
introducing errors into the system. 

5.3 Integrate Subsystems & Components 

The subsystems and components of the information system are integrated 
into the final product in the processes of this step. 

5.4 Conduct Integration Tests & Reviews 

The actual tests and reviews of the information system are carried out in 
this activity. 

5.5 Decide Whether To Proceed 

After the entire information system is integrated and tested, acceptance or 
rejection of the system is decided during this step of the integrate and test 
phase. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition: Manage Integrate & Test Phase 

5.1.1 Evaluate Metric Information 


Metric information is collected and evaluated to track the resource 
estimation to this point in the development. 


Artifacts 

User Roles 

Tools 

Methods 

I&T 

Performance/ 
Metric Reports 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Project Manager. 


5. 1.2 Re-evaluate Risk Areas 


Risk areas are re-evaluated as directed by the management plan to 
determine what planning modifications are needed. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Lessons 
Learned 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Project Manager. 


Framework Activity Definition 


Demonstration Framework 
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5.1.3 Document Changes to Plans 

Status and change reports are created to reflect changes to the plans. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Plan 

Updates 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Plan Updates is in state Completed. 

5.1.4 Modify & Update Plans 

Modifications and updates are made to the appropriate sections of the plan 
documentation. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

■ 


Completion: Artifact Management Plan is in state InProgress. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition: Conduct Risk & Management Control Activities 

5.2. 1 Collect Metric Information 

Metric information is collected for the evaluation and tracking of the 
information system. 


Artifacts 

User Roles 

Tools 

Methods 

I&T 

Performance/ 
Metric Reports 

System Designer 

Subsystem 

Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by System Designer. 


5.2.2 Document Metric Information 

The metric information collected in the previous step is documented in this 
process. 


Artifacts 

User Roles 

Tools 

Methods 

I&T 

Performance/ 
Metric Reports 

System Designer 

Subsystem 

Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Artifact Performance/Metric Reports is in state Completed. 


Framework Activity Definition 


Demonstration Framework 
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5.2.3 Assign Responsibility for Change Proposals 


Resolution for change proposals is assigned in this process. 


Artifacts 

User Roles 

Tools 

Methods 

I&T 

Engineering 

Change 

Proposals 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


5.2.4 Assign Responsibility for Deficiency Reports 

Resolution responsibility for deficiency reports is assigned in this process. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Status 
Reports 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


5.2.5 Assign Responsibility for Discrepancy Reports 


Resolution responsibility for discrepancies is assigned in this process. 


Artifacts 

User Roles 

Tools 

Methods 

I&T 

Discrepancy 

Reports 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


Demonstration Framework 


Framework Activity Definition 
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Decomposition: Integrate Subsystems & Components 

5.3.1 Test Subsystems & Components 


Each component and subsystem is thoroughly tested during this step of the 
integrate and test phase. 


Artifacts 

User Roles 

Tools 

Methods 

I&T QA Specs, 
Procs, Criteria, 
& Results 

I&T QE A 

Specs, Procs, 
Criteria, & 
Results 

Verification 

Tester 

Validation Tester 
Field Tester 
Quality 

Assurance Tester 

Test Tools 



Completion: Sign-off by Quality Assurance Tester. 


5.3.2 Integrate Next lower-level Component 

This process is repeated until all of the components are integrated into the 
whole system. 


Artifacts 

User Roles 

Tools 

Methods 

I&T 

Integration 



Integration 
Test Results 

Coder 



SMAP-DID- 

A200 





Completion: Sign-off by Integration Coder. 
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5.3.3 Prepare Documentation 

The documents for the integrate and test phase are prepared in this 
process. 


Artifacts 

User Roles 

Tools 

Methods 

I&T SA Specs, 
Procs, Criteria, 
& Results 

I&T SPA 

Specs, Procs, 
Criteria, & 
Results 

Integration 

Coder 

Verification 

Tester 

Validation Tester 
Field Tester 
Quality 

Assurance Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifacts are in state Completed. 

Decomposition: Conduct Integration Tests & Reviews 

5.4. 1 Conduct Verification Of Product vs Design Specs 


The integrated information system is verified against the design 
specifications to insure the resulting system is consistent with the design. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Ver. 

Verification 

MS Word 


Specs, Procs, 
Criteria, & 

Tester 

MS Draw 


Results 

Subsystem 

Designer 

MacDraw Pro 




MicroGraphix 

Designer 



Completion: Sign-off by Verification Tester. 
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Framework Activity Definition 
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5.4.2 Prepare for Validation 


If the validation procedures have not yet been completed, then they are 
completed at this time. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Specification 

Validation Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Validation Tester. 


5.4.3 Document V&V Activities 


Results from all V&V activities are recorded in the documentation. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Verification 

MS Word 

IDEFO 

Specification 

Tester 

MS Draw 

IDEF3 


Subsystem 

Designer 

MacDraw Pro 



Validation Tester 

MicroGraphix 

Designer 




AI0 




AI3 



Completion: Artifact Assurance Specification is in state Completed. 


<?-J2 
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Decomposition: Decide Whether To Proceed 

5.5. 1 Evaluate Reviews 

Reviews of the integration tests are evaluated at this time. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Review 
Reports 

Project Manager 
Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 

5.5.2 Evaluate Status Reports 

The status reports that were generated during this phase are evaluated. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Status 
Reports 

Project Manager 
Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

- 


Completion: Sign-off by Project Manager. 
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5.5.3 Perform Test Readiness Review 

The test readiness review is conducted and the conclusion of the integrate 
and test phase is completed in this process. 


Artifacts 

User Roles 

Tools 

Methods 

I&T Status 
Reports 

I&T 

Integration 
Test Results 

I&T 

Information 
System Post- 
Integration 
Tests 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor. 

Decomposition: Deliver Information System 

6. 1 Manage Deliver Information System Phase 

In this process, all of the management planning activities are conducted 
for the coordination of the delivery phase of the development. 

6.2 Conduct Formal Testing 

Formal tests of the completed information system are conducted in the step 
of the delivery phase. If any deficiencies or discrepancies are discovered, 
the steps to rectify them are taken before making delivery of the system. 

6^ Conduct Configuration Audits 

The final configuration audits are made before the delivery. This step is to 
insure that the actual performance of the information system, as 
determined through tests, complies with the requirements. 

6.4 Decide Whether to Proceed 

The accept or reject decision is made at this point in the delivery phase. 

6.5 Assign Responsibility for Change Proposals 

Any change proposals that have been created during the delivery phase are 
assigned to those responsible for making the changes during this step. 


Framework Activity Definition 


Demonstration Framework 
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6.6 Assign Responsibility for Deficiency Reports 

Any deficiency reports are assigned to individuals for correction. 

6.7 Assign Responsibility for Discrepancy Reports 

Any discrepancy reports are likewise assigned to those responsible for 
making appropriate changes to the system. 

6.8 Generate Version Description Document 

A version description document is created that details the specifics about 
the current version of the information system. This document is updated 
as newer versions come in to use. 

6.9 Generate User’s Guide 

A user’s guide, detailing all of the functionality of the system, is created 
and documented. 

6.10 Perform User Training 

At this point, the end users of the system are trained in the operation of the 
system. 

Decomposition; Manage Deliver Information System Phase 

6.1.1 Collect Metric Information 

Metric information is collected for the tracking and evaluation of the 
information system. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Performance/ 

Metrics 

Reports 

System Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by System Designer. 
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6.1.2 Document Metric Information 


Metric information is documented in this step of the delivery phase. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Performance/ 

Metrics 

Reports 

System Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Artifact Performance/Metrics Reports is in state Completed. 


6.1.3 Evaluate Metric Information 


The metric information that was documented in the previous step is 
evaluated to track the status of the information system. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Performance/ 

Metrics 

Reports 

A&D Status 
Reports 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Customer/Sponsor. 
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Demonstration Framework 
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6.1.4 Re-evaluate Risk Areas 


Risk areas are re-evaluated as directed by the management plan to 
determine what planning modifications are necessary. 


Artifacts 

User Roles 

Tools 

Methods 


A&D Lessons 
Learned 

SMAP-DID- 

R006 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Project Manager. 
6.1.5 Document Changes to Plans 


... j 

Any changes necessary from the previous step are recorded in change 
reports. 


Artifacts 

User Roles 

Tools 

Methods 


A&D 

Discrepancy 

Reports 

A&D Review 
Reports 

A&D 

Engineering 

Change 

Proposals 

A&D Lessons 
Learned 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 




Completion: Artifacts are in state Completed. 
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6.1.6 Modify & Update Plans 

The changes suggested in the previous process are made to the appropriate 
planning documents. 


Artifacts 

User Roles 

Tools 

Methods 

Management 

Plan 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

AIO 

AI3 

IDEFO 

IDEF3 


Completion: Artifact Management Plan is in state InProgress. 

Decomposition: Conduct Formal Testing 


6.2.1 Conduct Testing of System 

Formal testing of the system is performed and the test results recorded. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Acceptance 
Test Results 

Verification 

Tester 

Validation Tester 
Field Tester 
Quality 

Assurance Tester 

Test Tools 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Quality Assurance Tester. 


Framework Activity Definition 
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6.2.2 Analyze Acceptance Test Results 


The test results from the formal testing procedures are analyzed in this 
process. 


Artifacts 

User Roles 

Tools 

Methods 

A&D Lessons 

Quality 

MS Word 

Statistical 

Learned 

Assurance Tester 

MS Draw 

Analysis 

A&D 

Quality 



Engineering 

Assurance 

MacDraw Pro 


Change 

Proposals 

Specialist 

MicroGraphix 

Designer 


A&D Status 
Reports 


Excel 




Lotus 123 



Completion: Sign-off by Quality Assurance Specialist. 
6.2.3 Conduct Acceptance Review 


The acceptance review is held and any problems with the information 
system are discovered. 


Artifacts 

User Roles 

Tools 

Methods 

A&D Review 

Customer/ 

MS Word 


Reports 

Sponsor 

MS Draw 


> 

Project Manager 

MacDraw Pro 




MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor. 
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6.2.4 Document Acceptance Review 


The results of the acceptance review are recorded in this step. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Acceptance 
Test Results 

A&D Review 
Reports 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Acceptance Test Results is in state Completed. 


6.2.5 Perform V&V Activities 

The verification and validation activities that can be performed at this point 
in the development are conducted in this process. 

Decomposition: Perform V&V Activities 

6.2.5. 1 Conduct Verification Activities 


All verification activities specified in the assurance specification are 
conducted at this point. 


Artifacts 

User Roles 

Tools 

Methods 

A&D Ver. & 
Val. Results 

Verification 

Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Test Tools 



Completion: Sign-off by Verification Tester. 


Framework Activity Definition 


Demonstration Framework 
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6.2. 5.2 Conduct Validation Testing 

Validation testing is performed on the information system in this process. 


Artifacts 

User Roles 

Tools 

Methods 

A&D Ver. & 
Val. Results 

Validation Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Test Tools 



Completion: Sign-off by Verification Tester. 


6.2. 5.3 Document V&V Findings 


Results of the V&V activities are documented in the assurance 
specifications and the management control and status reports. 


Artifacts 

User Roles 

Tools 

Methods 

A&D Review 

Validation Tester 

MS Word 


Reports 

Verification 

MS Draw 


A&D Status 
Reports 

Tester 

MacDraw Pro 


Quality 

Assurance Tester 

MicroGraphix 

Designer 





Field Tester 




Completion: Artifacts Status Reports and Review Reports are in state 
Completed. 
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Decomposition: Conduct Configuration Audits 

6.3.1 Accept or Reject System 


Based upon the results of the two previous audits, the information system is 
accepted or rejected. 


Artifacts 

User Roles 

Tools 

Methods 

A&D Status 
Reports 

Customer/ 

Sponsor 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor. 

6.3.2 Perform Physical Configuration Audit 

The Physical Configuration Audit is likewise conducted at the end of this 
phase. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Information 
System Post- 
Acceptance 
Test 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 
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6.3.3 Perform Functional Configuration Audit 

The Functional Configuration Audit is conducted at the end of this phase. 


Artifacts 

User Roles 

Tools 

Methods 

A&D 

Information 
System Post- 
Acceptance 
Test 

Customer/ 

Sponsor 

Project Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Manager. 

Decomposition: Maintain Information System 

7. 1 Collect Metric Information 

Measurements/benchmarks are made on the system in this process. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Performance/ 

Metrics 

Reports 

Maintenance 

Coder 

Field Tester 

Test Tools 
MS Word 

Cost Analysis 

Statistical 

Analysis 


Completion: Sign-off by Field Tester 
7.2 Document Metric Information 

The measurements are documented and performance problems are 
identified. 


Artifacts 

User Roles 

Tools 

Methods 

SEX) 

Performance/ 

Metrics 

Reports 

Maintenance 

Coder 

Field Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Cost Analysis 

Statistical 

Analysis 


Completion: Artifact Performance/Metrics Reports is in state Completed. 
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102 


7 J3 Evaluate Discrepancy Reports 

Like engineering change proposals, discrepancy reports are examined and 
evaluated against the requirements and design documents to determine 
whether changes should be made. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Discrepancy 

Reports 

Project Leader 

System Designer 

Subsystem 

Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 
7.4 Evaluate Change Proposals 


In this process, the Engineering Change Proposals are examined and 
evaluated to determine whether the changes should be incorporated into the 
system. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Engineering 

Change 

Proposals 

Project Leader 

System Designer 

Subsystem 

Designer 

Maintenance 

Coder 

Field Tester 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


Framework Activity Definition 


Demonstration Framework 
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7.5 Document Discrepancy Reports 

The results of the evaluation of the discrepancy reports are documented in 
this process. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Discrepancy 

Reports 

System Designer 

Subsystem 

Designer 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Discrepancy Reports is in state Completed. 

7.6 Document Change Proposal Report 

The results of the evaluation of the change proposals are documented at 
this stage. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Engineering 

Change 

Proposals 

SMAP-DID- 

R005 

Project Leader 

System Designer 

Subsystem 

Designer 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Engineering Change Proposals is in state Completed. 
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7.7 Review Discrepancy Reports 

After changes to the system are made as a result of the discrepancy reports, 
a review is conducted to make certain that the system is in conformance 
with the design and requirements. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Discrepancy 

Reports 

SMAP-DID- 

R004 

SEO Review 
Reports 

SMAP-DID- 

R008 

System Designer 

Subsystem 

Designer 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


7.8 Review Change Proposal Reports 


After the changes have been made, the change proposals are compared to 
the updated system to insure that the quality of the system is maintained. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Engineering 

Change 

Proposals 

SEO Review 
Reports 

System Designer 

Subsystem 

Designer 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Project Leader. 


Framework Activity Definition 


Demonstration Framework 


















105 


Sj 

7.9 Make Changes to Information System 

Once the reports for change have been completed and reviewed, the 
Information System is modified to reflect those changes. 


Artifacts 

User Boles 

Tools 

Methods 

SEO Updates 

Maintenance 

Coder 

Emacs 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

C++ 

Motif 

dbx 

Lint 

X Windows 



Completion: Sign-off by Maintenance Coder. 

7.10 Acceptance Testing 

The updated system must now be checked to insure that it is operating 
correctly. This process is performed to complete this step in the 
development. 


Artifacts 

User Roles 

Tools 

Methods 

SEO Updates 

Field Tester 
Quality 

Assurance Tester 

Test Tools 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Quality Assurance Tester. 
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7. 1 1 Perform V&V Activities 

The new system must pass through the V&V process before being used in 
the field. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Discrepancy 

Reports 

SEX) 

Engineering 

Change 

Proposals 

SEO 

Performance/ 

Metrics 

Reports 

SEO Review 
Reports 

SEO Status 
Reports 

Verification 

Tester 

Validation Tester 

Test Tools 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Verification Tester and Validation Tester. 


7.12 Perform Regression Testing 


Regression testing of the system is done in this step. 


Artifacts 

User Roles 

Tools 

Methods 

SEO Status 
Reports 

Field Tester 

Test Tools 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 

Statistical 

Analysis 


Completion: Sign-off by Field Tester. 
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7.13 Update Documentation 

All of the documentation associated with the old version of the system must 
be updated to reflect the changes that have been added. 


Artifacts 

User Roles 

Tools 

Methods 1 

SEO Updates 

Project Leader 

MS Word 


SEO Updates 

System Designer 

MS Draw 

E 

SEO Updates 

Subsystem 

Designer 

Maintenance 

Coder 

Field Tester 

MacDraw Pro 

MicroGraphix 

Designer 

Excel 

Lotus 123 

AI0 

All 

AI1X 

AI3 

IDEF1X 

IDEF3 

Gantt Charts 


Completion: Artifacts are in state Completed. 


7.14 Review All Products 

All products that were modified during this maintenance iteration must be 
reviewed before being put in to everyday use. 


Artifacts 

User Roles 

Tools 

Methods 

Assurance 

Specification 

Management 
Control & 

Status Reports 

Management 

Plan 

Product 

Specification 

Document 

Project Leader 

Customer/ 

Sponsor 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 
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Completion: Sign-off by Customer/Sponsor. 
7. 15 Document Review Results 


The results of the product review are recorded at this time to provide the 
required traceability of the development of the system. 


Artifacts 

User Roles 

Tools 

Methods 

SEO Review 
Reports 

Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Artifact Review Reports is in state Completed. 


7.16 Determine Readiness to Proceed 


This process is 
operation. 

the final review 

before putting the 

new system in to 

Artifacts 

User Roles 

Tools 

Methods 

SEO Updates 

... 

Customer/ 

Sponsor 

Project Manager 
Project Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer/Sponsor. 
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7. 17 Assign Resolution Responsibility 

If any problems with the new system are found, then individuals are 
assigned to resolve the problems and the Maintenance Phase is repeated. 


Artifacts 

User Roles 

Tools 

Methods 

SEO 

Engineering 

Change 

Proposals 

Group Leader 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Group Leader. 


7.18 Conduct User and Operations Training & Support 


In this process, the users of the system are trained in the use of the new 
functionality of the system. 


Artifacts 

User Roles 

Tools 

Methods 

SEO Updates 

Customer Service 

End User 

End User 

Manager 

MS Word 

MS Draw 

MacDraw Pro 

MicroGraphix 

Designer 



Completion: Sign-off by Customer Service. 
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5 Status and Future Directions 


With the completion of this demonstration framework, the “code” with 
which the Framework Programmable Platform will be “programmed” has 
been completed. The next logical step is to test the concept of framework 
programming by building a demonstration system. As this framework was 
being developed, concurrent work was focusing on the development of a 
demonstration FPP to do just that. This demonstration system is being 
built off of the designs produced at earlier stages of the FPP project and will 
be demonstrated in the very near future. 

The purpose of this demonstration FPP will be to demonstrate a proof of 
concept of the framework programming concept and to highlight the 
advantages that can be gained by using a process description to control and 
manage a development process. Indirectly, this proof of concept will also 
show that the effort required to build a framework will be well worth the 
effort as the development experience of an organization can be captured and 
maintained. 

Upon completion of the demonstration FPP, effort should focus on scaling 
the functionality up to produce a production environment. This effort could 
be directed in two ways. The first is to attempt to build an entire 
environment from scratch that will result in a fully integrated system over 
which the FPP has complete control. The second strategy involves building 
modules that can be integrated with existing environments to incorporate 
portions of the FPP functionality. As the demonstration FPP represents the 
end of this phase of FPP development, the choice of implementation strategy 
will have to wait for the definition of the next phase. 
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A Appendix A - System Development Processes Comparison 

In the following pages, a chart relating the various activities of several 
system development processes is provided. The columns of the chart 
represent the various sources surveyed. The bold words in the chart 
represent a Major Phase of a particular development process. With this 
chart, an attempt was made to have the rows represent similar activities 
within each of the different processes. These common activities would then 
serve as a reference point from which to compare and contrast the other 
activities found in the processes. The cells that are empty do not 
necessarily indicate that the step or similar steps are not performed for a 
particular method, but instead reflect that the materials used describe the 
processes to different levels of detail. 
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